下面以“大牛直播SDK 的 RTSP 播放器遇到 RTP 不带 Marker 位(M bit)”为切入点,结合 RTP/RTCP 基础 与 H.264/H.265/AAC 的负载规范,说明发送端如何规范打包 二、发送端(打包器)如何“规范打包”:H.264/H.2651) 通用约束 时间戳:同一帧(AU)内的所有 RTP 包 使用相同的 RTP 时间戳;视频时钟为 90 kHz。 负载≈1200–1300B; TCP/RTSP 内嵌(interleaved)虽无 UDP 头,但仍建议与 UDP 一致的分片尺寸,利于复用与中间件处理。 三、发送端(打包器)如何“规范打包”:AAC(MPEG4-GENERIC) AU 头:按 SDP 中的 sizeLength/indexLength/indexDeltaLength 生成 AU-headers-section 接收端(大牛直播SDK RTSP 播放器侧):实现 “M 位优先 + 时间戳变化 + FU 完整 + 超时兜底” 的复合切帧算法,这既符合规范精神,又能兼容“不带 M 位”的常见设备。
RTSP被用于建立的控制媒体流的传输,它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送,但一般情况RTSP本身并不用于转送媒体流数据。 媒体数据的传送可通过RTP/RTCP等协议来完成。 一次基本的RTSP操作过程是:首先,客户端连接到流服务器并发送一个RTSP描述命令(DESCRIBE)。 客户端再分析该SDP描述,并为会话中的每一个流发送一个RTSP建立命令(SETUP),RTSP建立命令告诉服务器客户端用于接收媒体数据的端口。 流媒体连接建立完成后,客户端发送一个播放命令(PLAY),服务器就开始在UDP上传送媒体流(RTP包)到客户端。 在播放过程中客户端还可以向服务器发送命令来控制快进、快退和暂停等。 第五步: 数据传送播放中 S->C:发送流媒体数据 // 通过RTP协议传送数据 6.
关于使用rtp推流,TSINGSEE青犀视频团队实际已经研发了很长时间,其中也碰到了不少问题,比如RTP推流客户端无法解析播放,或者遇到不同的报错,但这些目前都已经有了比较完善的解决办法。 在使用RTP推流时,默认ffmpeg使用的打包模式是packetization-mode=1,本文我们和大家分享另一个比较实用的技巧,就是使用ffmpeg配置rtp打包模式。 如何修改打包模式? 关于RTP打包模式的说明如下: 目前ffmpeg默认使用的是1: Not interleaved 模式,针对客户的需要,服务端不支持STAP-A的组包模式,需要每个包单独发送,所以需要配置Single 配置完成后,还有个问题,需要配置pkt size,否则I帧无法完整发送,默认pkt size是1024个字节,而一般I帧都大于1024个字节,导致I帧发送不完整,图像传输失败,需要配置pkt size,在rtp url后面加上如下所示内容: rtp://192.168.99.138:6666?
前面我们花了较多的篇幅来介绍了RTSP协议的一些细节,但是rtsp传输,本质上涉及三种协议,RTSP、RTP以及RTCP。RTSP主要负责连接建立,销毁及一些其他的控制。 而实际涉及媒体数据传输使用的是RTP协议,本节我们来介绍一下RTP协议。 RTP概览 RTP是一种应用层协议,传输层协议可以是TCP或者UDP(UDP多一些)! RTP数据包由两部分组成,一部分是RTP Heaeder,一部分是RTP body,RTP Header占用最少12个字节,最多72个字节;另一部分是RTP Payload,用来封装实际的数据负载,如封装 下面我们来仔细看下RTP Header和RTP Body的组织形式! RTP包格式示意图 ? CSRC 由于RTP Header中CC的值为0,所以表示CSRC在本数据包中的个数为0,在此处没有,RTP HEADER中允许有0-15个CSRC。 RTP Payload ?
❝将PCM数据打包为RTP包。 /* 数据有效性判断 */ if (info.encoder_type == AudioEncoder::CodecType::kOther) return; 打包为 RTP // 对于连续的音频包,需要连续的timestamp。 timestamp += sizeof(int16_t) * encoder->NumChannels() * encoder->RtpTimestampRateHz()/100; /* 创建rtp包 packet.SetTimestamp(timestamp); packet.SetSsrc(ssrc); uint8_t *payload = packet.SetPayloadSize(buffer.size()); /* 装载rtp
特点:RTSP协议本身不传输媒体数据,而是通过控制连接建立命令和控制,媒体数据通过其他协议(如RTP)传输。它提供了丰富的控制选项,方便用户操作,且可以穿越NAT和防火墙。应用场景:1. RTP(Real-time Transport Protocol)简介:RTP是一个实时传输媒体数据的协议,通常与RTSP一起使用。它负责在网络上传输音视频数据。 直播服务 应用场景:在直播场景中,RTP协议为高质量的音视频传输提供了保障,RTP能确保观众能够实时观看到流畅、清晰的视频内容。 总结RTMP、RTSP、RTP、HLS、DASH这些协议在流媒体传输领域各有特点,但也有一些共同点。分别在实时视频传输中各有优势,选择哪种协议取决于具体的应用场景、网络条件以及设备兼容性等因素。 RTMP、RTSP、RTP、HLS、DASH这些协议在服务于流媒体传输方面有着共同的目标和追求,同时也在各自擅长的领域发挥着重要作用。
问题背景: 前面讲解了PS、TS、FLV这三种媒体封装格式,现在新开一个系列讲解下传输协议,这里面会包含RTP、RTSP、HLS、RTMP等。 其中大家看到这些开始播放,暂停、快播这些播放按钮背后的功能就需要靠RTSP来支持。看到这个图像视频数据,其实靠的是RTP协议传输过来的。RTCP呢? RTP协议既可以理解为传输层也可以理解为应用层,这么说是因为RTP负载可以放到RTSP上进行传输,通过二元交织通道方式实现。 然后通过RTSP、SIP或者HTTP等协议和接收端协商。 2.RTP数据包的生成: 通过RTSP等协议的SDP信息协商好了RTP数据包的发送目的和传输方式,我们就需要把音视频数据打包成RTP包,用UDP发送给接收端了。
二、RTSP / RTP 协议机制深度解读要理解轻量级 RTSP 服务 SDK 的价值,必须先回顾 RTSP 与 RTP 的核心机制。 简而言之:RTSP 管“会话”,RTP 管“数据”,SDP 管“说明”。 内置协议栈:RTSP/RTP/SDP 由 SDK 自研实现,不依赖第三方服务。 多会话能力:单设备支持多客户端同时拉流。 四、关键技术实现细节 RTP 打包 视频(H.264/H.265):支持 FU-A(大帧分片)、STAP-A(多帧打包)。 音频(AAC):每帧 1024 个采样点,时间戳递增。 从 技术层面 来看,它是对 RTSP/RTP/SDP 标准协议的工程化、轻量化实现,使得任意 Android 设备都能以最小的依赖成本,直接对外提供合规的实时流。
此时得到的为原始数据 涉及技术或协议: 摄像机:CCD、CMOS 拾音器:声电转换装置(咪头)、音频放大电路 2、数据编码: 使用相关硬件或软件对音视频原始数据进行编码处理(数字化)及加工(如音视频混合、打包封装等 2、RTSP(Real Time Streaming Protocol,实时流传输协议) RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。 RTSP提供了一个可扩展框架,数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接,为选择发送通道如UDP、组播UDP与TCP提供途径,并为选择基于RTP上发送机制提供方法。 代理服务器的缓存功能也同样适用于RTSP,并且因为RTSP具有重新导向功能,可根据实际负载情况来切换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。
2、RTSP(Real Time Streaming Protocol,实时流传输协议) RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。 RTSP提供了一个可扩展框架,数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接,为选择发送通道如UDP、组播UDP与TCP提供途径,并为选择基于RTP上发送机制提供方法。 RTSP语法和运作跟HTTP/1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。 代理服务器的缓存功能也同样适用于RTSP,并且因为RTSP具有重新导向功能,可根据实际负载情况来切换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。
随着H.265的普及,越来越多的开发者希望大牛直播SDK(Github)能支持低延迟的RTSP H.265播放,并分享相关经验: 实现思路: 对rtsp来说,要播放h265只要正确解析sdp和rtp包即可 sprop-vps, sprop-sps, sprop-pps等等, 具体请参考相关 文档,建议解析sprop-vps, sprop-sps, sprop-pps. 2.2 SDP 举例: m=video 0 RTP RTP 打包格式 实际中其实就用到两种格式,一种是一个nal单元打包到一个rtp包中。 一种是nal单元比较大,分片打包在多个rtp中. 3.1 单个Nal单元打包: PayloadHdr 把 NAL单元头填入就好. 3.2 Nal单元分片打包: PayloadHdr还是拷贝NAL 相关资料分享:RTP Payload Format for HEVC:http://pike.lysator.liu.se/docs/ietf/rfc/77/rfc7798.xml
背景 在事先Android平台RTSP、RTMP转GB28181网关之前,我们已经实现了Android平台GB28181的接入,可实现Android平台采集到的音视频数据,编码后,打包按需发到GB28181 和我们之前实现的轻量级RTSP服务网关模块类似,我们要做的是,实现RTSP或RTMP流,按需打包对接到GB28181服务平台。 轻量级RTSP服务模块、RTSP|RTMP转GB28181网关模块和内置RTSP网关模块的区别和联系: 内置轻量级RTSP服务模块和内置RTSP网关模块,核心痛点是避免用户或者开发者单独部署RTSP或者 内置RTSP网关模块,实际上是RTSP/RTMP拉流模块+内置轻量级RTSP服务模块组合出来的。 数据源来自RTSP或RTMP网络流,拉流模块完成编码后的音视频数据回调,然后,汇聚到内置轻量级RTSP服务模块。RTSP|RTMP转GB28181网关模块,和内置RTSP网关模块数据源接入一样。
产品设计方面,媒体流支持最新GB28181-2016的UDP和TCP被动模式,参数配置,支持注册有效期、心跳间隔、心跳间隔次数、TCP/UDP信令设置,支持RTP Sender IP地址类型、RTP Socket 本地端口、SS-R-C、RTP socket 发送Buffer大小、RTP时间戳时钟频率设置,支持注册成功、注册超时、INVITE、ACK、BYE状态回调。 待收到服务端的Ack后,发送编码、打包后的媒体流数据。在此期间,按照设定间隔,定时发送keepalive。 如上图所示,模块除了常规的音视频参数配置外,系统可同时亦或单独实现如RTMP推送、RTSP推送、轻量级RTSP服务、实时录像、GB28181前端接入。 、RTMP和音视频采集、编码传输等有了多年积累,GB28181接入,对我们来说,只是在现有架构的基础上,完成信令交互和数据打包传输(H264, H265打包成PS流,然后拆成RTP包发送即可),RTP传输支持
之上,默认使用端口1935; 2.RTMPE在RTMP的基础上增加了加密功能; 3.RTMPT封装在HTTP请求之上,可穿透防火墙; 4.RTMPS类似RTMPT,增加了TLS/SSL的安全功能; 二、RTSP RTSP具有重新导向功能,可视实际负载情况来转换提供服务的服务器,可以避免过大的负载集中于同一服务器而造成延迟。 RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。 RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的。RTP广泛应用于流媒体相关的通讯和娱乐,包括电话、视频会议、电视和基于网络的一键通业务(类似对讲机的通话)。 四、RTCP协议(RTP Control Protocol)RTP控制协议 提供数据分发质量反馈信息,RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。
3、RTSP(Real Time Streaming Protocol,实时流传输协议) RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。 RTSP提供了一个可扩展框架,数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接,为选择发送通道如UDP、组播UDP与TCP提供途径,并为选择基于RTP上发送机制提供方法。 RTSP语法和运作跟HTTP/1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。 代理服务器的缓存功能也同样适用于RTSP,并且因为RTSP具有重新导向功能,可根据实际负载情况来切换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。
RTSP提供了一个可扩展框架,数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接,为选择发送通道如UDP、组播UDP与TCP提供途径,并为选择基于RTP上发送机制提供方法。 RTSP语法和运作跟HTTP/1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。 代理服务器的缓存功能也同样适用于RTSP,并且因为RTSP具有重新导向功能,可根据实际负载情况来切换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 直播1.png 3、RTCP(Real-time Transport Control Protocol,实时传输控制协议 RTCP是RTP的配套协议,为RTP媒体流提供信道外的控制。 RTCP和RTP一起协作将多媒体数据打包和发送,定期在多媒体流会话参与者之间传输控制数据。
-> cmd [vxWorks *]# rtp Display process list [vxWorks *]# rtp [rtpId or Name] Display summary information about processes in memory [vxWorks *]# rtp exec <filename> Execute a RTP file named <filename> [vxWorks -X : (Vx7) do not return the exit code of foreground RTP, just return 0 -- : mark the end of "rtp exec " options [vxWorks *]# rtp attach Display the attachment list [vxWorks *]# rtp attach [rtpId or Name] *]# rtp detach Detache the shell session from the current memory context [vxWorks *]# rtp foreground
RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTCP协议或者RTSP协议)。 报文由两个部分构成--RTP报头和RTP的负载: RTP报文由两部分组成:报头和有效载荷。 RTP报头格式如图6.7所示,其中: 1.V:RTP协议的版本号,占2位,当前协议版本号为2。 2. 其控制流由RTSP协议来提供。 RTP协议的使用: RTP的使用实例之一如上图: 上面是某省IPTV2.0早期的一个数据包的情况。从包中可以看出RTP是怎么和RTSP配合一起使用的。 从包402到411为RTSP的协商过程,RTSP在PLAYer命令后数据包就到来。紧跟其后412包就是一个mpeg 的PES包,它是有由rtp来承载的TS来形成。
在底层,RTSP 通常与 RTP(Real-time Transport Protocol) 和 RTCP(RTP Control Protocol) 配合使用: RTP 负责音视频帧的实际传输; RTCP 跨时钟同步:RTSP/RTP/RTCP 三者时间基不同,需要动态校正与重采样。 RTP Header:序列号、时间戳、SSRC; PS Packet:系统头 + 音视频打包; Transport Mode:UDP 单播为主,部分实现支持 TCP fallback。 随后,RTMP、GB28181、录制模块分别从该缓冲区读取帧进行编码、打包或输出。 → GB28181:将标准 RTSP 流重新打包为 PS 流,并通过 SIP/INVITE 注册上级平台; RTMP → GB28181:适用于移动推流或自定义直播源纳入国标平台; 多协议并发输出:
RTP是啥? VxWorks的RTP,全称是Real-Time Process,可以翻译为实时进程。 在6.0之前,VxWorks使用的是single的内存空间,操作系统与应用程序是不分离的。 从6.0开始,VxWorks引入了RTP。这个RTP在许多地方都与其它操作系统的进程差不多,例如对POSIX的兼容性。 所以了解UNIX/Linux进程模型的程序猿,很快就可以熟悉RTP的创建、执行或者终止。 ? 不过RTP是专门为RTOS设计的,为了满足实时性的需求,它与其它系统的进程还是有很多不同的。 有了RTP,就可以在用户模式下执行应用程序和操作系统的其它功能,这些功能在内核和应用程序之间具有清晰的划分。这种体系结构通常被称为进程模型。 同时,6.x与5.5保持了高度的兼容。 关于RTP的具体信息,咱们后文慢慢道来。 这正是: VX系统与时进,内核应用若比邻。 历史项目好兼容,不损实时高性能。